Masterarbeit «Besoldung in der Feuerwehr»

English Version

Problem

LODUR bietet Feuerwehren Funktionen zur Administration. Dies umfasst hauptsächlich folgende Bereiche: Verwaltung Angehörige der Feuerwehr, Besoldung, Einsatzrapportierung, Materialverwaltung, Kurs anmeldung und Übersicht Ausbildungs stand. Das Modul «Besoldung» verursacht beim Auftraggeber B. Wahlstroem Engineering GmbH, einen hohen Supportaufwand. In diesem Modul erfolgt die Konfigurationen der Besoldungsregeln, eine Aufgabe für die zur Zeit fast jede Feuerwehr den Support in Anspruch nimmt. Der Auftraggeber ist deshalb daran interessiert, die Anzahl Supportfälle mit einem Redesign des Moduls «Besoldung» zu reduzieren oder bestenfalls ganz zu eliminieren. Die Ursachen für die vielen Supportfälle sind einerseits die starke Verteilung von einzelnen Einstellungen auf verschiedene Fenster und andererseits die fachliche Komplexität der Besoldungsregeln. Denn jede Feuerwehr hat ihre eigenen, teilweise völlig unterschiedlichen, Besoldungsregeln.

Vereinfacht gesagt definieren die Besoldungsregeln verschiedene Soldansätze sowie die Abrechnungsart für unterschiedliche Tätigkeiten. Die Abrechnungsart bestimmt, ob eine Tätigkeit pro Stunde, pauschal oder in einer Mischform vergütet wird. Besoldungsregeln werden normalerweise einmalig eingerichtet. Nach Bedarf erfolgen dann mehr oder weniger oft Anpassungen, wenn zum Beispiel eine Feuerwehr ihre Soldansätze an die Teuerung anpasst.

Phase «Analyse»

Die Phase «Analyse» umfasst die Identifikation der Stakeholder, die Festlegung der Usabiltiy-Ziele sowie die benutzerentrierte Erhebung der Anforderungen. Die Phase «Analyse» ist aufgeteilt in Iterationen im Sinne von Teilphasen. Das heisst, dass die Inhalte der einzelnen Iterationen jeweils anders sind. Die Teilphasen haben dennoch einen iterativen Charakter. Die Detailplanung einer Iteration erfolgt jeweils am Ende der Vorhergehenden.
Im Zentrum der Phase «Analyse» stehen die benutzerzentrierte Analyse-Methode ethnografische Interviews nach Cooper et al. (2010) sowie ein Online-Fragebogen.

Phase «Design»

In der Phase «Design» geht es um die Erarbeitung eines Lösungsvorschlages in Form von Wireframe Prototypen. In dieser Phase haben sich mehrere Benutzer die Zeit genommen, unsere Prototypyen bei einem Walkthrough zu evaluieren. Die Phase «Design» ist ebenfalls in Iterationen unterteilt im Sinne vom Wiederholen einer Folge von Schritten. Das heisst, dass in jeder Iteration der Prototyp aufgrund der Erkenntnisse der letzten Iteration weiter entwickelt wird und jede Iteration mit einer Evaluation.

Methodische Vertiefung

Zur Zeit existiert kein gesamtheitliches Mapping zwischen den Aspekten des Problemraums und dem fertigen Design einer Benutzeroberfläche. In der Praxis basiert die Ableitung des Designs aus den Analyse-Resultaten hauptsächlich auf der Erfahrung der Interaction Designer. Deshalb ist die Überwindung vom Gap zwischen dem Problem- und Lösungsraum eine Art «Magic».

Hübscher et al. (2012) erarbeiten für diesen Gap ein Mapping. Dieses Mapping-Modell hat zum Ziel, eine Landkarte als Orientierung zwischen dem Problem- und Lösungsraum zu bieten.

Im Rahmen der methodischen Vertiefung haben wir zwei Vorgehensweisen für die Überwindung des Gaps verglichen: Zuerst haben wir das Design der Prototypen gemäss den Prinzipien der Struktur- und Rasterebene nach Garrett (2012) erarbeitet. Vor der Evaluation mittels Walkthrough haben wir den Prototypen mit dem Mapping-Modell nach Hübscher et al. (2012) evaluiert, der zweiten Vorgehensweise mit einem Mapping-Modell.
Die Erkenntnisse der beiden Evaluationen zeigen den Unterschied der Prototyp-Vollständigkeit der jeweiligen Vorgehensweisen.